Shadow profile and environment for mobile security

ABSTRACT

A user device receives a communication that contains a link or an attachment and sends the link or the attachment to a virtual user device stored externally with respect to the user device. Actions to be performed with respect to the user device are executed on the virtual user device. The virtual user device determines whether the link or attachment is malicious. The user device receives an indication of whether the link or the attachment is malicious and displays an indication that the link or the attachment is safe to open when the link or attachment is not malicious.

BACKGROUND

Millions of users fall victim to phishing, malware, and ransomwareattacks each year. A heavy burden exists on users to identify maliciousactivities, such as bad links, emails, executable, and websites, whichmay spread the attacks. The attacks constitute a significant economicloss in both consumer and corporate settings in the form of time spentin remediation, data loss, and money spent in paying ransoms.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an exemplary environment in whichsystems and/or methods, described herein, may be implemented;

FIG. 2 is a diagram of exemplary components of a device that may beincluded in the environment shown in FIG. 1;

FIG. 3 is a flow chart of an exemplary process of determining whether alink or attachment is malicious;

FIG. 4 is a diagram illustrating an exemplary environment associatedwith the process of FIG. 3;

FIG. 5 is a flow chart of an exemplary process in which an applicationmay be provided false information about a user; and

FIG. 6 is a diagram showing an embodiment in which a hypervisor may beused for detecting malicious links or attachments.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements. Also, the following detailed description does notlimit the invention.

Systems and methods described herein represent a user device as a shadowdevice instantiated in a virtualized manner in a cloud. The shadowdevice may be identical in model, memory, applications, and data to theuser device. The shadow device may be instrumented to detect maliciousactivity and fake data. In addition, the shadow device may be virtuallyfirewalled to protect the user device from cyber attacks such asphishing, malware, and ransomware attacks.

Implementations described herein relate to methods, devices, and systemsfor creating a shadow device that emulates a user device. The shadowdevice may include a virtual device that is stored or implemented in thecloud. The shadow device may be identical to the user device and actionsperformed on the user device may be emulated by the shadow device sothat the user and the user device may be synchronized. For example, anyinteractions performed by a user on the user device may be replicated bythe shadow device. The shadow device may be used to open suspiciouslinks or attachments received by the user device to protect the userdevice from malicious activity. In addition, the shadow device may store“dummy” data or false data that may be provided to third parties toprotect the identity and other information associated with a user of theuser device.

FIG. 1 is a diagram illustrating an exemplary environment 100 in whichsystems and/or methods, described herein, may be implemented. As shownin FIG. 1, environment 100 may include a user equipment (UE) 110, anetwork 120, and a cloud 130. Cloud 130 may store shadow UEs 140-1 to140-N (wherein N may be equal to any integer greater than or equal to 1,referred to herein individually as shadow UE 140 or 140-x andcollectively as shadow UEs 140). UE 110 may store applications (apps)150-1 to 150-N (wherein N may be equal to any integer greater than orequal to 1, referred to herein individually as app 150 or 150-x andcollectively as apps 150).

UE 110 may include any device capable of communicating via a network.For example, UE 110 may correspond to a mobile communication device(e.g., a mobile phone, a smart phone, a personal digital assistant(PDA), or a wireline telephone), a computer device (e.g., a laptopcomputer, a tablet computer, or a personal computer, a notebook, anetbook, a wearable computer (e.g., a wrist watch, eye glasses, etc.)),a gaming device, a music playing device, a home appliance device, a homemonitoring device, a set top box, a computation device onboard a machine(a smart car, drone, robot, etc.), a computation terminal (e.g., akiosk, an automatic teller machine (ATM), etc.), or another type ofcommunication or computation device.

UE 110 may store one or more apps 150. Apps 150 may allow a user tointeract with a number of providers via UE 110. App 150 may include, forexample, an Internet browsing app, a text messaging app, an email app, asocial media app, a two-factor authorization app, a gaming app, anonline shopping app, a navigation app, an app to allow a user to accessinformation associated with shadow UE 140, or any other type of app.

Network 120 may generally include one or more wired, wireless and/oroptical networks that are capable of receiving and transmitting data,voice and/or video signals, including multi-media signals that mayinclude voice, data and video information. For example, network 120 mayinclude one or more access networks, Internet Protocol (IP) multimediasubsystem (IMS) networks, evolved packet core (EPC) networks, or othernetworks. The access network may include one or more wireless networksand may include a number of transmission towers for receiving wirelesssignals and forwarding the wireless signals toward the intendeddestinations. The network may include a wireless communications networkthat connects subscribers (e.g., UE 110) to other portions ofenvironment 100 (e.g., cloud 130). In one example, the access networkmay employ other cellular broadband network standards such as 3rdGeneration Partnership Project (3GPP) fifth generation (5G) and futurestandards. In another implementation, network 120 may include along-term evolution (LTE) network. Network 120 may further include oneor more satellite networks, one or more packet switched networks, suchas an IP-based network, a local area network (LAN), a wide area network(WAN), a personal area network (PAN) (e.g., a wireless PAN), a wirelesslocal area network (WLAN), an intranet, the Internet, or another type ofnetwork that is capable of transmitting data.

Cloud 130 may include a 5G multi-access edge computing (MEC) networkarchitecture that enables cloud computing capabilities and anInformation Technology (IT) service environment at the edge of acellular network, such as network 120. MEC technology may be designed tobe implemented at cellular base stations or other edge nodes and mayenable flexible and rapid deployment of new applications and servicesfor customers. By running applications and performing related processingtasks closer to the cellular customer, network congestion may be reducedand application performance may improve. Cloud 130 may store one or moreshadow UEs 140 and information associated with shadow UEs 140, such as adatabase of safe and/or malicious links (not shown). In otherimplementations, cloud 130 may interface with a fourth generation (4G)network, such as an LTE network.

Shadow UE 140 may include a virtual UE that is a replica of UE 110.Shadow UE 140 may be implemented in response to a user of UE 110downloading a mobile application on UE 110 and performing a registrationprocess. As discussed in connection with FIG. 5, the registrationprocess may include configuring the type of data that shadow UE 140sends to apps 150. Shadow UE 140 may emulate UE 110 so that actionsperformed on UE 110 are performed on shadow UE 140 and shadow UE 140 maybe synchronized with UE 110. Data received at UE 110 and sent by UE 110may be automatically streamed to shadow UE 140 so that shadow UE 140 maymirror the actions performed on UE 110. For example, if a user of UE 110is accessing app 150, the functions performed by the user with respectto app 150 are performed on shadow UE 140 and saved on cloud 130. Thedata exchanged between UE 110 and app 150 may be automatically streamedto cloud 130 so that shadow UE 140 may mirror UE 110. In addition, acurrent state of UE 110 may be recorded and saved on cloud 130. Forexample, before a link is opened on shadow UE 140, a “snapshot” ofshadow UE 140 may be taken. In this way, if the link is malicious, thestate of UE 110 before the link was opened may be maintained and UE 110may continue operating based on the state of UE 110 prior to the linkbeing opened.

Because cloud 130 may be implemented via a 5G MEC architecture, theremay be virtually no latency between the actions occurring on UE 110 andthe emulation of the actions on shadow UE 140. In addition, becauseshadow UE 140 is a replica of UE 110, it may not be possible formalicious parties/software to detect that shadow UE 140 is operating inan emulated environment. Currently, malware may be able to detect whenthe malware is running in an emulated environment and the malware maynot release a malicious payload when it detects that it is running inthe emulated environment. However, since shadow UE 140 is a replica ofUE 110 and because there may be virtually no latency (or undetectablelatency) between actions performed on UE 110 and the emulated actionsperformed on shadow UE 140, the malware may not be able to detect thatshadow UE 140 is running in an emulated environment on cloud 130. Inthis way, the malware may release a malicious payload on shadow UE 140and UE 110 may be protected from the malicious payload.

In addition, since shadow UE 140 is a replica of UE 110, a user of UE110 may be able to access shadow UE 140 in the event that UE 110 isunavailable (e.g., UE 110 is lost or stolen). For example, if UE 110 islost, a user of UE 110 may order a replacement UE. Before thereplacement UE arrives, the user may be able to access shadow UE 140through a web browser or via other means in order to access apps 150 andother information stored on UE 110. For example, if the user requires anapp 150 stored on UE 110 to input a code for two-factor authorization toaccess the user's email services, the user may access the two-factorauthorization app stored on shadow UE 140 to obtain the code. Inaddition, once the replacement UE arrives, the user may be able totransfer the exact state of UE 110 when UE 110 was lost from shadow UE140 to the replacement UE. Since shadow UE 140 is a replica of UE 110,shadow UE 140 may store the most recent states and interactions thatoccurred with respect to UE 110.

As used herein, the term “user” is intended to be broadly interpreted toinclude UE 110 and/or a person using UE 110. Also, the terms “user,”“owner,” “consumer,” “subscriber,” and/or “customer” are intended to beused interchangeably.

The number of devices and/or networks, illustrated in FIG. 1, isprovided for explanatory purposes only. In practice, additional devicesand/or networks, fewer devices and/or networks, different devices and/ornetworks, or differently arranged devices and/or networks than thoseillustrated in FIG. 1 may be used. Also, in some implementations, one ormore of the displayed devices or networks may perform one or morefunctions described as being performed by another one or more of theother devices or networks. The devices and networks shown in FIG. 1 mayinterconnect via wired connections, wireless connections, or acombination of wired and wireless connections.

FIG. 2 is a diagram of exemplary components of a device 200 that maycorrespond to one of the components of UE 110, network 120, and/or cloud130. As illustrated, device 200 may include a bus 210, a processing unit220, a memory 230, an input component 240, an output component 250, anda communication interface 260.

Bus 210 may permit communication among the components of device 200.Processing unit 220 may include one or more processors ormicroprocessors that interpret and execute instructions. Additionally oralternatively, processing unit 220 may be implemented as or include oneor more application specific integrated circuits (ASICs), fieldprogrammable gate arrays (FPGAs), or the like.

Memory 230 may include a random access memory (RAM) or another type ofdynamic storage device that stores information and instructions forexecution by processing unit 220, a read only memory (ROM) or anothertype of static storage device that stores static information andinstructions for the processing unit 220, and/or some other type ofmagnetic or optical recording medium and its corresponding drive forstoring information and/or instructions.

Input component 240 may include a device that permits an operator toinput information to device 200, such as a button, a switch, a keyboard,a keypad, a mouse, a microphone or the like. Output component 250 mayinclude a device that outputs information to the operator, such as adisplay (e.g., a liquid crystal display), a printer, a speaker, a lightemitting diode (LED), etc.

Communication interface 260 may include one or more transceivers thatenables device 200 to communicate with other devices and/or systems. Forexample, communication interface 260 may include one or more radiofrequency (RF) receivers, transmitters, and/or transceivers and or moreantennas for transmitting and receiving data. Communication interface260 may also include a modem or Ethernet interface to a LAN or othermechanism for communicating with other devices.

As described herein, device 200 may perform certain operations inresponse to processing unit 220 executing software instructionscontained in a computer-readable medium, such as memory 230. Acomputer-readable medium may be defined as a non-transitory memorydevice. A memory device may include space within a single physicalmemory device or spread across multiple physical memory devices. Thesoftware instructions may be read into memory 230 from anothercomputer-readable medium or from another device via communicationinterface 260. The software instructions contained in memory 230 maycause processing unit 220 to perform processes described herein.Alternatively, hardwired circuitry may be used in place of or incombination with software instructions to implement processes describedherein. Thus, implementations described herein are not limited to anyspecific combination of hardware circuitry and software.

Although FIG. 2 shows exemplary components of device 200, in otherimplementations, device 200 may contain fewer components, differentcomponents, differently arranged components, or additional componentsthan depicted in FIG. 2. Alternatively, or additionally, one or morecomponents of device 200 may perform one or more tasks described asbeing performed by one or more other components of device 200.

FIG. 3 is a flow chart of an exemplary process 300 of determiningwhether a link or attachment is malicious. FIG. 4 is a diagramillustrating an exemplary environment 400 associated with the process ofFIG. 3.

Process 300 may begin when UE 110 receives a communication from a sendercontaining a link or an attachment (block 310). As shown in FIG. 4, UE110 may receive a link or attachment from sender 410 (420). For example,app 150 may include a mail app an electronic mail app 150 may receive anemail with an attachment from sender 410. As another example, app 150may include a text messaging app and text messaging app 150 may receivea text message including a link from sender 410.

Process 300 may continue when UE 110 sends the link or attachment toshadow UE 140 (block 320). For example, as shown in FIG. 4, UE 110 mayforward the link or attachment to shadow UE 140 (430). In oneimplementation, UE 110 may automatically forward the link or attachmentto shadow UE 140 prior to allowing the user to access the link orattachment. For example, app 150 may correspond to an email app, a textmessage app, an app associated with shadow UE 140, or another type ofapp and app 150 may flag the link or attachment as suspicious. App 150may automatically forward the flagged link or attachment to shadow UE140 without any user input. As another example, app 150 mayautomatically forward all links or attachments to shadow UE 140 prior toallowing the user to access the link or the attachment.

In another implementation, a user may request that the link or theattachment be forwarded to shadow UE 140 for inspection. For example,the user may receive a link or an attachment from sender 410 (e.g., viaan email or a text message) and app 150 associated with shadow UE 140may open on UE 110 and display a message indicating that the link orattachment may be malicious. App 150 may further provide the user withan option to send the link or attachment to shadow UE 140. The user mayindicate via app 150 that the link or attachment should be sent toshadow UE 140. As another example, the user or UE 110 may receive theattachment or link and may determine that the link or the attachment maybe malicious. In this case, the user may open app 150 associated withshadow UE 140 and request that UE 110 send the attachment or link toshadow UE 140.

Process 300 may continue when shadow UE 140 determines whether the linkor the attachment is malicious (block 330). For example, shadow UE 140may receive a link from UE 110 and may look up the link in a database todetermine whether the link is known to be malicious or safe. Forexample, a database with known malicious and/or known safe links ordestinations may be stored in cloud 130 or in another location. If thelink or a portion of the link is in the database, shadow UE 140 maydetermine whether the link is malicious or safe. As another example,shadow UE 140 may be able to verify a certificate authenticity of alink, which may be effective against static low sophistication attacks,such as phishing sites. If shadow UE 140 verifies that a certificateassociated with the link is authentic, shadow UE 140 may determine thatthe link is safe.

As another example, shadow UE 140 may receive the link or the attachmentand may open the link or the attachment. Prior to opening the link orthe attachment, shadow UE 140 may record and store the current state ofUE 110. Shadow UE 140 may open the link or the attachment when the linkis not found in the database or when shadow UE 140 is unable todetermine the authenticity of the certificate associated with the link.Alternatively, shadow UE 140 may open the link or the attachment withoutlooking up the link in the database or attempting to verify theauthenticity of the certificate associated with the link.

In some instances, malware may be able to determine that it is runningin a simulated environment. In these situations, the malware may notrelease the payload or interact with an operating system running on thesimulated environment. Therefore, in these cases, a link or anattachment may be determined to be safe because the payload is notreleased. However, because shadow UE 140 is a replica of UE 110 andbecause there is virtually no latency between actions performed on UE110 and the emulated actions performed on shadow UE 140, malware runningon shadow UE 140 may not be able to detect that it is running in anemulated environment on cloud 130. That is, since shadow UE 140 has allof the characteristics of UE 110, the malware may not be able todetermine that shadow UE 140 is not UE 110. Therefore, when shadow UE140 opens a malicious link or attachment, the malware may release themalicious payload since the malware is unable to detect that shadow UE140 is running in an emulated environment.

When shadow UE 140 opens the link or the attachment, if the attachmentor the destination associated with the link contains malware, themalware may release a malicious payload on shadow UE 140. Since themalicious payload is released on shadow UE 140, UE 110 may be protectedfrom the malicious payload. If a malicious payload is released, shadowUE 140 may determine that the link or the attachment is malicious andmay prevent UE 110 from opening the malicious link or attachment. Sinceshadow UE 140 stored a state of UE 110 prior to opening the link or theattachment, UE 110 may continue operating based on the state before thelink or the attachment was opened. If the attachment or the destinationassociated with the link does not contain malware, shadow UE 140 maydetermine that the link or the attachment is safe for UE 110 to open.

Process 300 may continue when shadow UE 140 forwards an indication ofwhether the link or the attachment is malicious to UE 110 (block 340).As shown in FIG. 4, shadow UE 140 may forward an indication of whetherthe link or attachment is malicious to UE 110 (440). If the link or theattachment is not malicious, UE 110 may display an indication that thelink or the attachment is safe. For example, if shadow UE 140 determinesthat an email attachment is safe, email app 150 may display anindication near the attachment or near the email that the attachment isnot malicious (e.g., a checkmark, an icon, changing a color of textassociated with the attachment, a written indication that the attachmentis safe, etc.). Similarly, if shadow UE 140 determines that a linkembedded in a text message is safe, text message app 150 may display anindication near the text message or near the link that the link is safe.

If shadow UE 140 determines that the link or the attachment ismalicious, app 150 associated with the link or the attachment may notifythe user that the link or the attachment is malicious. For example, app150 may display an indication near the link or the attachment that thelink or the attachment is not safe and should not be opened. App 150 mayfurther prevent the user from opening the link or attachment byautomatically deleting the link or attachment. In one implementation,app 150 may delete the email or text message that contains the link orattachment to prevent the user from opening the malicious link orattachment. App 150 may further notify the user that shadow UE 140 hasdetected a malicious link or attachment and has deleted the link or theattachment and/or an email or text message associated with the maliciouslink or attachment. App 150 may additionally flag sender 410 of themalicious link or attachment and may forward all future receivedcommunications from sender 410 to shadow device 140. In addition, UE 110may report the sender of the email or the text message, a websiteassociated with the malicious link or the malicious attachment, oranother entity associated with the malware to a third party, such as anetwork provider associated with network 120.

The method described above with respect to FIGS. 3 and 4 protects UE 110from malicious links and/or attachments. Because shadow UE 140 runs on a5G MEC platform (or a fast 4G platform), there may be virtually nolatency between actions performed on UE 110 and shadow UE 140.Therefore, the process described above may be performed quickly andaccurately to ensure that UE 110 is safe from malware attempting to harmUE 110.

FIG. 5 is a flow chart of an exemplary process 500 in which an app maybe provided false information about a user. Process 500 may begin when auser accesses app 150 or downloads app 150 to UE 110 (block 510). Forexample, a user may open an app store affiliated with UE 110 and maydownload app 150 to UE 110. Alternatively, a user may visit athird-party app store or a website to download app 150. Additionally, auser may access app 150 via a second application stored on UE 110. Forexample, app 150 may include a third-party app, such as a quiz app, thatis granted access to information about the user and/or UE 110 via asocial media application downloaded on UE 110.

Process 500 may continue when shadow UE 140 performs an assessment onapp 150 to determine whether app 150 is potentially dangerous or harmfulor whether app 150 has been compromised (block 520). Since shadow UE 140emulates the actions of UE 110, when app 150 is downloaded to UE 110,shadow UE 140 may have access to app 150. A potentially dangerous orharmful application may misuse user information after being installed onUE 110. For example, app 150 may sell user information or contactinformation to a third party or otherwise leak a user's privacyinformation. In these instances, a user may not want to provide app 150with legitimate user information if app 150 is potentially dangerous. Inaddition, app 150 may become compromised and behave in an inappropriatemanner. For example, app 150 may become compromised by malwareattempting to perform exfiltration of data from UE 140. In thisinstance, a user may want to provide app 150 with dummy data that can betagged and traced.

Some websites may provide modified versions of existing applicationsthat request many permissions. For example, app 150 may include athird-party app that was created by a developer that is not themanufacturer of UE 110 or the owner of the website that offers app 150.A third-party app may require that a user of UE 110 permit thethird-party app to access information about the user and UE 110. Thepermissions requested by app 150 may include access to a user'slocation, personal information, contact information, history, an addressor identifier associated with UE 110, etc. Shadow UE 140 may perform arisk assessment on app 150 to determine whether app 150 is potentiallymalicious or dangerous. For example, shadow UE 140 may analyze who madeor distributed app 150 to determine whether app 150 is potentiallydangerous. In addition, shadow UE 140 may determine that app 150 ispotentially dangerous based on a number of permissions that app 150requests from the user. Shadow UE 140 may also determine that app 150 ispotentially dangerous by looking up app 150 in a database of potentiallydangerous applications, and/or other ways. In addition, shadow UE 140may determine that app 150 has been compromised when app 150 behaves inan inappropriate manner. For example, shadow UE 140 may determine thatapp 150 has been compromised if app 150 attempts to perform exfiltrationof data from UE 140.

Process 500 may continue when shadow UE 140 accesses settings associatedwith the user (block 530). A user may provide preferences regardinginformation to be sent to app 150 based on a risk associated with app150. For example, during registration, a user may be provided with auser interface to configure settings regarding privacy informationassociated with the user or UE 110.

For example, a user may indicate that if there is no risk associatedwith the app 150, shadow UE 140 may provide legitimate information aboutthe user to app 150. The user may further indicate that if app 150 ispotentially dangerous, fake or dummy data should be provided to app 150.In addition, the user may indicate that some legitimate information andsome fake information may be provided to app 150. In this instance, auser may determine which legitimate information (e.g., user name) shouldbe provided to app 150 and which fake information (e.g., userinformation) may be provided to app 150. A user may further indicatethat legitimate, but non-specific information may be provided to app150. For example, a user may opt to provide a current country or statewhere the user is located as geolocation information instead ofproviding a more specific address, such as a city or street.Alternatively, the user may indicate that fake or dummy data should beprovided to all apps 150. When a user indicates that fake or dummy datashould be provided, the user may choose the fake or dummy data toprovide. Alternatively, the user may indicate that random fake or dummydata may be provided.

In addition, a user may choose to provide legitimate contact informationthat is unused by the user. For example, a user may wish to accesscontent behind an access wall that requires that the user input contactinformation, such as a telephone number or email address. A user mayindicate that a legitimate email address or telephone number that is nottypically used by the user may be provided in order to access thecontent. In addition, during the initial registration, a user mayprovide more than one email address or telephone number. For example,the user may indicate that if app 150 is not suspicious, a first emailaddress should be provided to app 150. In addition, the user mayindicate that if app 150 is potentially dangerous, a second emailaddress should be provided to app 150. In this case, the user may beable to access emails sent to both email addresses, but may use thesecond email address for receiving ads, coupons, etc. In this way, apotentially dangerous application may not have access to an emailaddress associated with the user that may contain private information.Additionally, a user's primary email address may not be inundated withunwanted emails or spam.

In one implementation, the dummy data may include false contactinformation associated with the user. For example, the dummy data mayinclude a false email address or a false phone number. The dummy datamay additionally include fake geolocation data associated with the user.The dummy information may further include a fake contact list and fakeinformation associated with the contacts on the fake contact list. Inaddition, the dummy information may include a fake browsing history or afake profile associated with the user.

The dummy data may further include fake information associated with UE110, such as a fake Internet Protocol (IP) address. IP address spoofingmay include creating IP packets with a false source IP address for thepurpose of impersonating another computing system. IP address spoofingmay involve the use of a trusted IP address by network intruders toovercome network security measures, such as authentication based on IPaddresses. In order to prevent an IP address associated with UE 110 tobe used for illegitimate purposes, a user of UE 110 may not want toprovide a legitimate IP address when app 150 is potentially dangerous.In addition, a user may wish to provide other false informationassociated with UE 110. Therefore, the dummy data may include a fake IPaddress, a false phone number, a false International Mobile EquipmentIdentifier (IMEI), or another fake address or identifier associated withUE 110.

In addition, a user may choose to provide dummy data when app 150 hasbeen compromised. In this case, a user may additionally choose toprovide dummy data that has been tagged and can be traced. For example,if app 150 has been compromised by malware and is attempting toexfiltrate data from UE 110, a user may choose to provide tagged dummydata to app 150. In this way, the tagged dummy data may be traced topotentially determine who is attempting to exfiltrate the data from UE140.

Process 500 may continue when shadow UE 140 provides app 150 with dataassociated with the user and/or UE 110 based on the risk assessment andthe settings information (block 540). For example, based on thesettings, when shadow UE 140 determines that app 150 is not dangerous,shadow UE 140 may provide app 150 with legitimate user information. Inanother example, shadow UE 140 may determine that app 150 is potentiallydangerous and not secure. In this instance, based on the user'ssettings, shadow 140 may provide app 150 with dummy data when app 150 ispotentially dangerous. For example, if shadow UE 140 determines that app150 is potentially dangerous and app 150 requests user geolocation dataand contact information, shadow UE 140 may provide app 150 with fake ornonspecific geolocation data and fake contact information based on theuser's settings. In this way, a user may feel secure that his or herpersonal information is secure from potentially malicious applications.

The method described above with respect to FIG. 5 may allow a user tomaintain security and privacy when app 150 is downloaded to UE 110. Themethod may further prevent the user from experiencing annoyances such asunwanted telephone calls, telemarketer calls, unwanted emails, and spamemails. The method may additionally protect a user's contacts from beingtargeted by malicious or unwanted communications.

FIG. 6 is a diagram showing an embodiment 600 in which a hypervisor,such as a type 2 hypervisor, may be used for detecting malicious linksor attachments. Environment 600 may include UE 110, app 150, type 2hypervisor 610, and shadow app 620.

In one implementation, when 5G or a fast 4G platform is not availabledue to a user's location or for another reason, a user may be unable toaccess shadow UE 140. When a user is downgraded to a slower network,latency issues may prevent the user from accessing shadow UE 140. Inthis situation, a user may continue to monitor links and attachmentsusing type 2 hypervisor 610 on UE 110. Type 2 hypervisor 610 may includea software version of a hypervisor that may run on UE 110. As shown inFIG. 6, type 2 hypervisor 610 may include a shadow app 620 that emulatesapp 150. Shadow app 620 may be identical to app 150 and actionsperformed with respect to app 150 may be performed on shadow app 620.Shadow app 620 may be used in a manner similar to shadow UE 140 to opensuspicious links or attachments received by app 150.

For example, when app 150 is an email app and app 150 receives acommunication, such as an email with an attachment, app 150 may send theattachment to shadow app 620. As another example, when app 150 is a textmessage app and app 150 receives a text message with an embedded link,app 150 may send the link to shadow app 620. Shadow app 620 maydetermine whether the link or attachment is malicious in a mannersimilar to the manner discussed with respect to FIGS. 3 and 4 in whichshadow UE 140 determined whether a link or attachment is malicious. Forexample, shadow app 620 may open a suspicious link or attachment and amalicious payload may be released on shadow app 620 instead of app 150.In this way, UE 110 may be protected from the malware since themalicious payload has not been released on app 150.

As shown in FIG. 6, instead of running app 150 via shadow UE 140 fromcloud 130, app 150 may be running directly as shadow app 620 on UE 110through type 2 hypervisor 610. In this manner, a user may continue to besecure when the user is unable to access shadow UE 140 on a 5G MECplatform or other fast computing platform (e.g., LTE).

In the preceding specification, various preferred embodiments have beendescribed with reference to the accompanying drawings. It will, however,be evident that various modifications and changes may be made thereto,and additional embodiments may be implemented, without departing fromthe broader scope of the invention as set forth in the claims thatfollow. The specification and drawings are accordingly to be regarded inan illustrative rather than restrictive sense.

It will be apparent that different aspects of the description providedabove may be implemented in many different forms of software, firmware,and hardware in the implementations illustrated in the figures. Theactual software code or specialized control hardware used to implementthese aspects is not limiting of the implementations. Thus, theoperation and behavior of these aspects were described without referenceto the specific software code—it being understood that software andcontrol hardware can be designed to implement these aspects based on thedescription herein.

To the extent the aforementioned embodiments collect, store or employpersonal information of individuals, it should be understood that suchinformation shall be collected, stored, and used in accordance with allapplicable laws concerning protection of personal information.Additionally, the collection, storage and use of such information may besubject to consent of the individual to such activity, for example,through well known “opt-in” or “opt-out” processes as may be appropriatefor the situation and type of information. Storage and use of personalinformation may be in an appropriately secure manner reflective of thetype of information, for example, through various encryption andanonymization techniques for particularly sensitive information.

What is claimed is:
 1. A method comprising: receiving, at a user deviceassociated with a user, a communication containing a link associatedwith a destination; accessing, by the user device, an application viathe destination; sending, by the user device, the link to a virtual userdevice stored externally with respect to the user device, whereinactions to be performed by the user device using the application areexecuted on the virtual user device, and wherein the virtual user devicedetermines a risk that the application is potentially malicious;receiving, at the user device, an indication of the risk that theapplication is potentially malicious; and providing, by the user device,user-configured setting information indicating multiple types of datathat the virtual user device provides to the application according tothe indicated risk and responsive to a request from the application,wherein the multiple types of data relate to at least one of the user orthe user device and include specific legitimate information, falseinformation, and non-specific legitimate information.
 2. The method ofclaim 1, wherein receiving the indication includes receiving theindication in response to the virtual user device performing a lookup ina database to determine whether the application is malicious.
 3. Themethod of claim 1, wherein receiving the indication includes receivingthe indication in response to the virtual user device selecting the linkto determine whether the application is malicious.
 4. The method ofclaim 1, further comprising: downloading, by the user device, theapplication, wherein the virtual user device provides randomly-generatedfalse information associated with the at least one of the user or theuser device to the application.
 5. The method of claim 1, furthercomprising: receiving a second communication that contains at least oneof a second link or a second an attachment; determining that amulti-access edge computing (MEC) platform implementing the virtual userdevice is unavailable; sending the second link or the attachment to ahypervisor on the user device; and receiving an indication from thehypervisor whether the second link or the attachment is potentiallymalicious.
 6. The method of claim 1, further comprising: preventing thelink from being opened when the risk indicates that the application ispotentially malicious.
 7. The method of claim 1, further comprising:deleting the communication when the risk indicates that the applicationis potentially malicious.
 8. A device comprising: a memory configured tostore instructions; and a processor configured to execute theinstructions to: receive, from a user device associated with a user, anindication of one or more actions performed with respect to the userdevice; execute the one or more actions so that the device issynchronized with the user device; receive, from the user device, acommunication containing a link associated with a destination, whereinan application is accessible to the user device via the destination;determine a risk that the application is potentially malicious; andprovide, to the application based on user-configured settinginformation, multiple types of data according to the indicated risk andresponsive to a request from the application, wherein the multiple typesof data relate to at least one of the user or the user device andinclude specific legitimate information, false information, andnon-specific legitimate information.
 9. The device of claim 8, wherein,when determining the risk, the processor is further configured toperform a lookup in a database to determine whether the application ispotentially malicious.
 10. The device of claim 8, wherein, whendetermining the risk, the processor is further configured to select thelink to determine whether the application is potentially malicious. 11.The device of claim 8, wherein, when determining the risk, the processoris further configured to determine whether a certificate associated withthe link is authentic.
 12. The device of claim 8, wherein the processoris further configured to: randomly generate the false information. 13.The device of claim 8, wherein the processor is further configured to:tag the false information so the false information can be traced;determine whether the application has been compromised; provide thefalse information associated with the user device to the applicationwhen the application has been compromised; and trace the falseinformation.
 14. The device of claim 8, wherein the device isimplemented on a multi-access edge computing (MEC) platform.
 15. Anon-transitory computer-readable medium containing instructions, theinstructions comprising: one or more instructions that, when executed bya processor associated with a virtual device, cause the processor to:receive, from a user device associated with a user, an indication of oneor more actions performed with respect to the user device; execute theone or more actions so that the virtual device is synchronized with theuser device; receive, from the user device, a communication containing alink associated with a destination, wherein an application is accessibleto the user device via the destination; determine a risk that theapplication is potentially malicious; and provide, to the applicationbased on user-configured setting information, multiple types of dataaccording to the indicated risk and responsive to a request from theapplication, wherein the multiple types of data relate to at least oneof the user or the user device and include specific legitimateinformation, false information, and non-specific legitimate information.16. The non-transitory computer-readable medium of claim 15, wherein theone or more instructions that cause the processor to determine the riskcomprise one or more instructions that cause the processor to perform alookup in a database to determine whether the application is potentiallymalicious.
 17. The non-transitory computer-readable medium of claim 15,wherein the one or more instructions that cause the processor todetermine the risk comprise one or more instructions that cause theprocessor to select the link to determine whether the application ispotentially malicious.
 18. The non-transitory computer-readable mediumof claim 15, wherein the one or more instructions that cause theprocessor to determine the risk comprise one or more instructions thatcause the processor to determine whether a certificate associated withthe link is authentic.
 19. The non-transitory computer-readable mediumof claim 15, wherein the instructions further comprise instructions thatcause the processor to: randomly generate the false information.
 20. Thenon-transitory computer-readable medium of claim 15, wherein the virtualdevice is implemented on a multi-access edge computing (MEC) platform.